Thread: Reversing a string declared as char[] works, but as char* it segfaults. Why?

Code:

// return ++a;
// b = --x == --y;
// while (*s++);

This is indeed ugly, but these practices will result in serious bugs..

Using explicit pointer arithmetic in critical software is generally frowned upon. MISRA 2004 rules 17.1 to 17.3 prohibit some particular cases of explicit pointer arithmetic that do not give rise to well-defined results. Rule 17.4 then states that “Array indexing shall be the only allowed form of pointer arithmetic”. All 4 rules are “required” rather than “advisory”, so 17.4 appears to make the preceding 3 rules redundant. The implication seems to be that developers who break 17.4 should at least honour 17.1 to 17.3.

How (un)safe is pointer arithmetic? | David Crocker's Verification Blog

Originally Posted by kodax

How (un)safe is pointer arithmetic? | David Crocker's Verification Blog

I could just as easy say that your code examples are bad because your commenting style does not comply with MIRSA 2004 Rule 2.2 that requires you to use the older "/* */" style comments. Or do only you get to pick and chose the rules?

That aside, I'm pretty sure that most will agree C usage in critical systems is significantly different from common and accepted C usage. It is definitely different from what you would expect an inexperienced novice to use to reverse characters in a string.

But back to being off topic - where are these serious bugs that you asserted will be in those bits of code?

You miss the point, even if you don't make errors, there's the likelihood that someone else will.

Potential pointer corruption.

If code assumes that pointers and integers are the same size (in an arithmetic context), there will be problems.
Pointer arithmetic is often a source of problems when migrating code. The ISO C standard dictates that incrementing a pointer adds the size of the data type to which it points to the pointer value. For example, if the variable p is a pointer to long, the operation (p+1) increments the value of p by 4 bytes (in 32-bit mode) or by 8 bytes (in 64-bit mode). Therefore, casts between long* and int* are problematic because of the size differences between pointer objects (32 bits versus 64 bits).

IBM Documentation

--->

What Mr. "I am always right" hasn't realized yet is that his code is buggy, despite all the "pointer leads to bugs" rhetoric. His code:

Code:

void a_reverse(char *buffer, const char *array, int length) { 
    int a = length;
    int b = 0;

    while (0 != a) {
        a = a - 1;
        buffer[b] = array[a];
        b = 1 + b;
     }
 
    buffer[b] = '\0';

    // WHY?!
    return;
}

Of course the buffer and array pointers (oh, the horror!) must point to valid memory, but what will happen if length is negative? What will happen if both pointers points to the same memory region? All his effort to "be right and everybody knows it" (obviously a fallacy) vanished right there.

Just because he doesn't feel confortable using pointers and tries to signal virtue... Comparing to his, this is way less buggy AND commented, in case anyone has doubts on what the routine is doing:

Code:

// Using restrict to tell the compiler the pointers cannot be the same.
// Yep... assumes both pointers are valid (notice: no 'length'!).
char *strrev( char * restrict out, const char * restrict in )
{
  // points out to the end of the buffer and puts a '\0' there.
  out += strlen( in );
  *out-- = '\0';
 
  //  while '\0' isn't found yet, copy chars in reverse order,
  // incrementing the input pointer, and decrementing the output pointer.
  while ( *in ) *out-- = *in++;
 
  // puts out back at the beginning and return it.
  return ++out;
}

The same assumptions apply: Both arguments must be valid pointers AND not pointing to overlapped regions (as his routine also implies -- but worse!) AND the output buffer must be the same size as the input buffer.

So... yep... keep trying. One day you'll enjoy using pointers...

Originally Posted by kodax

You miss the point, even if you don't make errors, there's the likelihood that someone else will.

You did, in your code, using 'arrays' instead of pointer arithmetic.

About #24, the same can be said if you use long instead of int (not pointers). On MS-ABI for x86-64 long and int have the same size, but on SysV ABI x86-64 long is the same as long long. This is problematic on Windows:

Code:

long x = -1L;

Since is 0xFFFFFFFF, not 0xFFFFFFFFFFFFFFFFL.

In the old MS-DOS int is 16 bits long and long is 32 (try it with TurboC, Borland C++ 3.1 and Microsoft C 6, as examples of good compilers for DOS).

ISO 9899 is clear on this: There's no garantees about primitive types sizes (only minimum recommendations).

To confuse pointer types is something a beginner suffers from. Of course, for example, char * and double * points to different objects and their addresses will be dealt differently. This isn't "insecure". This is a feature of the language.

Another thing to notice: [] operator is a shortcut to pointer arithmetic:

Code:

// this:
a[i] = 0;

// is exactly the same as this:
*(a + i) = 0;

Use return to exit early of a void function.

Code:

void abcd() {
    if (done) {
        return; 
    }
    // do something
}

Return statement is optional in that context, but it is necessary in x86-64 Assembly.